1. Field of the Invention
This invention relates to systems for testing software applications and more particularly relates to simulating permission-based access to computing resources.
2. Description of the Related Art
Considerable effort is required to design and develop software applications that perform effectively under a wide variety of conditions. Often, in an attempt to improve the effectiveness of specific functions, coding changes are made that behave differently than expected. Additionally, changes to one module of code may have unexpected effects on related modules. Furthermore, in some development environments such as an open source development environment, a large number of developers may make changes to the source code.
One method to deal with the dynamic nature of application development and find coding errors is to conduct a build and test sequence at regular intervals. FIG. 1 is a schematic block diagram depicting one embodiment of a prior art build and test system 100. As depicted, the build and test system 100 includes a user environment 110, a build script 115, a test script 120, one or more applications 130, a system level interface 140, and a set of resources 150 such as files 152, directories 154, devices 156, pipes 158, and processes 159. The build and test system 100 may be used to build and test applications under development and thereby identify coding errors, and the like, previous to general distribution of the applications.
The user environment 110 interacts with the user and may respond to commands and interface events involving the user. The user environment allows a user or administrator to define system level variables and parameters such as pathnames and user preferences. In certain implementations, the user environment 110 includes a command shell (not shown) that provides a command line prompt and responds to system level commands input by the user. In one embodiment, the command shell responds to user requests to list directories, view file permissions, and the like.
The build script 115 may retrieve or reference source code (not shown) and invoke a compiler to compile the source code into an executable application 130. In one embodiment, the build script 115 retrieves the latest revision of source code from a source code control system (not shown), and places the code in a designated directory and compiles the code into an executable file 130. After the application is built, the test script 120 executes and exercises the application 130 to find coding errors and may log results from such exercises into a test log (not shown). In conjunction with executing and exercising the application 130, an install process may be conducted to install the application.
The system level interface 140 is typically provided by the operating system and facilitates access to a set of resources 150 such as files 152, directories 154, devices 156, pipes 158, and processes 159. Many applications are constructed in a manner that requires access to restricted resources in order to properly build the application. For example, the build process may change system level files that are protected from access by ordinary users. However, the build and test process is sometimes conducted by ordinary users—particularly in an open source development environment where testing may be conducted by an unknown or unfamiliar party. In such a scenario, the build process may be aborted due to the insufficient privileges of the user.
One prior art solution to such a scenario imitates supervisor or root privileges for an ordinary user without actually securing such privileges. While this may be useful in certain instances and allow program flow to continue further than usual, such a solution will typically fail when a restricted resource is actually accessed.
Another prior art solution involves developing “relocatable” source code which uses relative references to computing resources and may be executed from an arbitrary location or directory. However, developing relocatable source code is a fairly tedious process that further complicates the testing process by introducing additional variables. Additionally, large programming projects may integrate modules maintained by external parties that do not support relocation. Furthermore, distributing a relocatable application may be undesirable due to licensing and security issues.
Given the aforementioned issues and challenges, what is needed are methods and systems to simulate access to restricted resources without actually using the restricted resources.